The Domain Name System (DNS) is a hierarchical naming system in which “domain names” map to many different types of data, such as an Internet Protocol (IP) address. For example, the domain name www.example.com could translate into the IP address 192.0.43.10. Every domain name is broken into “labels” that are separated by dots. The right-most label conveys the top-level domain (TLD), and each label to the left specifies a subdomain of the domain to the right. For example, in the domain name “sub.example.com,” “cam” is the top-level domain, “example” is the second-level domain, and “sub” is the third-level domain.
To translate DNS domain names to IP addresses, a network of domain nameserver computer systems (“domain nameservers”) maintain mappings of domain names to IP addresses. For any particular domain name, at least one domain nameserver is designated as being authoritative for that particular domain name. These authoritative nameservers are not only responsible for their particular domain or domains, but can also assign other name severs for their subdomains. For example, the owner of example.com can delegate authority to sub.example.com, a subtree of the example.com namespace. These delegations are not fixed in the DNS protocol, and domain owners can change them at any time.
Thus, in order for a client resolver to obtain the IP information that corresponds to a domain name, the client computer needs to be able to identify an authoritative nameserver for the domain name. Thus, an application program (e.g., a web browser) running on the client computer may send a query to a DNS resolver requesting the nameserver name and/or IP address associated with the particular domain name. In response, the resolver may either return the answer to the query if it is stored locally in the resolver's local cache, or identify an authoritative nameserver for the requested domain name by contacting one or more nameservers in order to reach the nameserver that can provide the appropriate nameserver names and/or IP addresses. Generally, resolvers are incorporated into operating systems of a client computer, which may in turn be connected to a DNS resolver for the client computer's Internet service provider.
The resolver contacts the nameservers in a hierarchical manner using a sequence of queries starting with the root server to find the server authoritative for the top level domain (e.g., “.com”). Subsequently, a query is provided to the obtained TLD server for the authoritative nameserver for the second-level domains, and those TLD nameservers can then provide information about the authoritative nameservers for the second-level domains. For example, an authoritative nameserver for the “.com” TLD will know the authoritative nameservers for the second-level example.com domain. Continuing in this hierarchical iterative delegation and referral manner as necessary, the authoritative nameservers for the domain name of interest can be identified. Once the appropriate response or responses are obtained from the appropriate authoritative nameserver the resolver returns them to the requesting application.
FIG. 1 is a diagram illustrating an exemplary related art process for obtaining the IP address for “secret.example.com.” As shown in FIG. 1, an application sends a request for the nameserver name and/or IP address associated with “secret.example.com” to a resolver (S110). Generally, resolvers have a local cache containing recent domain name lookups. Thus, the resolver may determine whether the cache includes the IP address mapping for secret.example.com locally, and if so, it will return the IP address to the application. If the cache does not contain the IP address mapping desired by the application, the resolver will determine whether it contains nameserver records (the NS set) for the authoritative zone, example.com (S120). If the cache includes the appropriate NS set, the resolver will directly contact the authoritative name servers and request the IP address mappings for secret.example.com. Upon receipt of a query response, the resolver will return the appropriate nameserver name and/or IP address to the application, otherwise the resolver will query the root nameserver for the nameserver name and/or IP address associated with “secret.example.com” (S130). In response, the root server provides the resolver with the designated authoritative nameserver for the appropriate TLD, in this case, the .com nameserver (S140). Since the process for resolving all names is recursive, meaning that the entire domain name (secret.example.com) is sent to each delegation in the namespace until it is answered by a zone that is authoritative for the name, the resolver must send additional queries. Accordingly, the resolver queries the .com nameserver for the nameserver name and/or IP address associated with “secret.example.com” (S150) and receives a response directing the resolver to the example.com nameserver (S160). The resolver then queries the example.com nameserver (S170) and receives a response indicating the nameserver name and/or IP address of “secret.example.com” (S180). After receiving the nameserver name and/or IP address, the resolver transmits the received address to the requesting application (S190).
As shown in FIG. 1, for a client resolver to simply look up “secret.example.com,” the DNS root nameserver, the .com nameserver, and the example.com nameserver are each asked for the entire domain name. While this recursive process has been employed for the past three decades, the process has always allowed the zones in DNS to observe many of the names and structure of zones below them in the hierarchy. For example, the operators of .com are able to see a great many of the domain names below (e.g., facebook.com or netflix.com). This can allow the operators to also see who is querying for these names, and at a rough approximation of how often. In essence, the DNS protocol discloses the entire domain name that users may query to each predecessor zone in the domain name. Accordingly, a new mechanism to minimize this information disclosure is needed.
Accordingly, exemplary embodiments consistent with the present invention include systems and methods for obfuscating the query a resolver sends to each authority in the predecessor list of zones. The goal of this approach is to allow clients to resolve names from a domain name authority through an arbitrary number of predecessor zones, without disclosing any more information to any of them beyond the domain they are already delegating to, thus minimizing confidentiality disclosures of named entities to untrusted parties.